<HTML>
<HEAD>
<title> rel3.0 </title>
</HEAD>
<BODY  bgcolor="#ffffff"  text="#000000">

<center>
<h1> rel3.0 </h1>
</center>

Date:     Fri, 18 Mar 88 23:50:32 EST
From:     Mike Muuss &lt;mike@BRL.ARPA&gt;

<p>
The most recent version is Release 2.3, 2-November-1987.  There is a
Release 3.0 comming up, targeted for May/June timeframe.  The new
3.0 release will include quite a variety of improvements, including
better rendering in RT, MGED support for X11r2, much improved MGED
support for SunView("suntools"), SGI 4D support, 3-D floating point
UNIX Plot and related plotting tools, and much more.

<p>
Here is an example sequence of what you are trying to do:

<p>
make a sph
r r1 u a
r r2 u a
g all.g r1 r2

<p>
Then use object editing to modify (rotate, translate, scale) the arc
r1/a and the arc r2/a.  Or, you could modify the arcs all.g/r1 and
all.g/r2, depending on your intent.

<p>
The Release 2.3 and earlier suntools support is in a very early form.
Quite honestly, if Bill Lindemann at Sun hadn't taken an evening and
done it, you wouldn't have anything yet.  BRL uses lots of Suns, but
not for vector graphics -- we have other devices for that.  We were hoping
that one of the BRL CAD recipients that was more heavily involved with
vector graphics on Suns might do some work to polish things up a bit.

<p>
However, I am pleased to note that Gary Moss has gotten excited about
running MGED on the Suns, and he has already made major progress in
improving the dm-sun.c support.

<p>
In a related area, Bill Mermagen has embarked on his first venture into
MGED (a learning exercise leading to a much more ambitious project).  For
starters, he will be adding vendor-independent pop-up sliders, so that
all displays without knob boxes will be able to use sliders on the screen
under control of the mouse/pen.  This will be a very significant addition.

<p>
Paul Stay is working on significant performance advances in handling splines.
Phil and I have been working on at least a half a million various things.
Last week Phil did the X11r2 support, which is pretty nice now.  I have
been preoccupied with videotape lately (not to mention being burried in
paperwork).  Phil and Terry and I will be making a "big push" in animation
tools in the Spring.

<p>
There has also been significant work in the predictive signature area
over the last year (sorry, not included in the normal distribution).

<p>
Lots of good stuff happening.  You can expect some terrific papers at the
BRL CAD Symposium this summer (plug, plug).  Contact &lt;Keith@BRL.ARPA&gt;
for details.
	Best,
	 -Mike
<hr>
Date:     Sat, 27 Feb 88 1:20:51 EST
From:     Mike Muuss &lt;mike@BRL.ARPA&gt;

<p>
This evening I made some worthwhile progress.  The RTCHECK program
now exists, and produces 3-D floating-point UNIX-plot pictures
of overlapping regions within an MGED database.  It can be used
as a standalone tool (with plot viewers like pl-fb, pl-sgi, tplot, etc),
or it can be run directly from within MGED.

<p>
From within MGED, the command "rtcheck" invokes the RTCHECK program
on the model from the current view, and then displays any overlaps
detected with yellow vectors added to the screen as "3-D overlays".
When RTCHECK is finished, the view can be rotated, zoomed, etc, to more
closely examine the overlaps.

<p>
As a by-product, MGED also got a new command called "overlay", which
allows a UNIX-plot file to be read in as an (optionally named) overlay.
This can be useful for studying a single ray-path in the context of
the model geometry.  (The RT program can give unix-plot dumps of ray
paths as a debugging option).  This could also be used to superimpose,
for example, measured spall-cloud contours with model geometry,
as a visualization aid.  There are probably many other uses, too.

<p>
The RTCHECK program is installed on VGR only.  Because I still have not
finished fixing the ARB8-becomes-ARB6 bug in MGED, this new version of
MGED is not yet installed.  However, the bug hunt should not drag out
more than a few more weeks.

<p>
Phil has been making good progress with pl-X, the UNIX-plot to X-windows
display program, the precursor to having X-windows support for MGED.

<p>
	Best,
	 -Mike
<hr>
Date:     Sat, 21 Nov 87 2:46:22 EST
From:     Mike Muuss &lt;mike@BRL.ARPA&gt;

<p>

<p>
Conversion of CSG solid models to bags of trimmed polygons is not an
easy task.  The "big-E" command does not do this, it outputs a list
of trimmed EDGES, but has no notion of the polygons (although it could
figure it out with some additional overhead and more code).

<p>
The strategy now being persued at BRL is to implement a several-stage
tool, that will:

<p>
	1)  tessalate each leaf note as a single solid object,
	2)  Apply the SIGGRAPH 86 work from Brown to perform the boolean
operations on the polygons, and
	3)  Output the result in a variety of useful forms.

<p>
Obviously part #2 is the hardest, and we have Jeff Schmitt from TSU
working on this code now.  Part #1 isn't trivial, but a first cut
won't be too bad.

<p>
We too have SGI's, including the new 4D machines, and would like to be
able to rotate trimmed wireframes and shaded polygons, for viewing.
We plan on having this capability by springtime.

<p>
Sorry I sound like a vendor, but we have limited manpower, and have to
schedule carefully.  Would be wonderful to be able to do everything
immediately.
(I don't even get to do my own research immediately, so there).

<p>
If anybody would like to contribute help to this effort, especially
in part #1, please contact &lt;Schmitt@brl.arpa&gt;, with a CC to me
&lt;Mike@BRL.ARPA&gt;.
	Best,
	 -Mike
<hr>
Date:     Sat, 21 Nov 87 2:19:33 EST
From:     Mike Muuss &lt;mike@BRL.ARPA&gt;

<p>
It is necessary to define SOLIDS (leaf nodes in the DAG) which are
composed of multiple polygons (typically triangular facets), the collection
of which encloses a finite volume.

<p>
Raytracing of such a solid presently works by determining potential
intersections for each facet, and weaving the result together into
a segment chain for boolean processing.  This is not unlike the ARB code.
(Which is a modified Cyrus and Beck algorithm -- possible because
ARBs are always convex, while the ARS may not be).

<p>
This code is being used at BRL now for the first time, and I expect it to
continue to evolve (especially in the area of performance).  However,
there should be enough to start with.
	Best,
	 -Mike
<hr>
Date:     Sat, 16 Apr 88 12:35:56 EDT
From:     Mike Muuss &lt;mike@BRL.ARPA&gt;

<p>
Right now, RT assumes square pixels in ordinary use.

<p>
If you are displaying on a non-square video system, eg, 768x512, for
NTSC use, then RT can be run to produce the appropriate size images
with -w768 -n512 options.

<p>
If you have a display that shows 512x512 images, such as an Ikonas,
then ordinarily all the RGB monitors are set to display this as a
square image (as you reported).

<p>
When such a framebuffer is used to create NTSC video, the pixel clock is
usually altered to "fill the screen", which results in a non-square
set of pixels, because the television image is not square.

<p>
In January, when we first started doing videotape work, Phil and I
began discussing another set of options to RT to pre-distort the grid
to compensate for what the NTSC encoding would do.  The module rt/worker.c
is where the changes would go.  Unfortunately for you, we never implemented
the change.  For now, we put up with the distortion when creating videotape.
My hope is that within the next few months, we will be switching to a
768x512 format for generating videotape (if SGI would ever deliver our
GenLock board), and then this issue will be moot (for us).

<p>
The only short-term workaround I can suggest is to run RT at the 768x512
resolution, and then pixscale into 512x512.  Then, when the lengthened
pixel clock widens the pixels, the image should look about right.
(If you feel like writing 20 lines of code, just changing RT would
probably be simpler, and certainly take less CPU time).

<p>
Hope this helps some,
	Best,
	 -Mike
<hr>
Date:     Thu, 21 Apr 88 17:13:53 EDT
From:     Phil Dykstra &lt;phil@BRL.ARPA&gt;

<p>
Due to popular demand, I have made X Window System support for MGED
available via anonymous ftp.  WARNING: you may experience difficulty
in that vector lists (struct vlist) have changed somewhat since the
last BRL-CAD release.  You are on your own there.

<p>
You can find it on VGR.BRL.MIL (a.k.a. BRL-VGR.ARPA, 192.5.23.6) in
pub/mgedx.shar.  The README file in that shar file follows:
-------------------
21 April 1988

<p>
This is a BRL-CAD "prerelease" of MGED support for the X Window System.
Expect to find this in our next major release sometime this summer.
Included is:

<p>
     dm-X10.c
	An X10R4 display manager for MGED.

<p>
     dm-X.c
	An X11R2 display manager for MGED (the prefered one).

<p>
     attach.diff
	A patch file for mged/attach.c to include the X display
	manager as an option.

<p>
     usepen.diff
	An optional patch file for mged/usepen.c which
	makes object selection nicer by only doing a redraw
	when the illuminated object changes.

<p>
To use,
1) add the apporiate file (dm-X10 or dm-X) to the mged directory.
2) Apply the patch(es).
3) Add the source file and object to mged/Makefile.loc
4) Define DM_X in Makefile.defs and include your X library, e.g.

<p>
MGED_CONFIG     = -DDM_SUNPW -DDM_X
MGED_LIBES      = -lsuntool -lsunwindow -lpixrect /usr/local/lib/libX.a

<p>
I have used this code on both a Sun 3/50 and the Cray-2, with a server
running on the Sun 3/50 only.  There is no support for color at this
time.  If anyone has any difficulties or adds additional capabilities
(e.g. color) please let me know.

<p>
- Phil Dykstra
&lt;phil@brl.arpa&gt;
<hr>
Date:     Mon, 29 Feb 88 12:37:29 EST
From:     "Gary S. Moss" (VLD/VMB) &lt;moss@BRL.ARPA&gt;

<p>
For those of you who still don't know:

<p>
	Black-on-white line drawings which resemble the old GIFT CALCOMP
hidden-line, plots can be generated from LGT, by setting the flag either
by typing "k 1" to the prompt, supplying the -k1 option on the shell
command line,  or by selecting the "special applications" menu, followed
by "hidden-line drawing".  An intermediate image will be generated which
is actually the result of stuffing the surface normals into the RGB
components of the pixels in the image.  Then, this image will be replaced
by the final result.  The computation of the second image may take a few
minutes, depending on the horsepower, load and available memory of the
host computer. Images of at least 512-by-512 pixels are usually necessary
to produce an accurate result.  HIRES (1024-by-1024) images require 1 meg.
of short integers (2 to 8 Megs, depending on the machine) extra memory for
the hidden-line computation, so be careful on smaller machines with HIRES,
or you will send them off to swap city.

<p>
	BW-IMPRESS may be used to plot these pictures on the IMAGEN
laser printers as follows:

<p>
	$ pix-bw -ntsc image.pix | bw-impress | ipr -qi300 -Limpress &

<p>
Locally, we also have RLE-IM, so another route is:

<p>
	$ rle-im image.rle | ipr -qim118 -Limpress &

<p>
	Please direct questions to &lt;moss@brl&gt;.

<p>
-moss
<hr>
Date:     Thu, 5 May 88 8:49:10 EDT
From:     Mike Muuss &lt;mike@BRL.ARPA&gt;

<p>
I have created a /usr/brlcad/ instead of having them live in /usr/brl/
so as to be similar to other machines. I have also updated your software
to the following specifications. Please forward the following to those
who will be using victor.brl.mil in the future.

<p>
Here is a brief description of the Silicon Graphics 4D Graphics Workstation
frame buffer and mged support.

<p>
1. The machine benchmarks around 9-12 times a vax 780 using rt.
2. The graphics capability is ~140K vector per second.
3. A larger screen size 1280x1024.

<p>
This system is a bit different than the Iris 3030 workstations in that
it always runs a window manager, so you don't have to run mex, the difference
is that you can get the full 24 bit color pictures even running the window
manager.

<p>
By default you are in "window mode" on the 4D, you can not open
additional windows.  To do this, DO NOT EXECUTE MEX because it will hang
the console (it can be killed from an rlogin at another terminal),
instead execute WSH.  If you do not want the ill-fated CSH or TCSH, then
execute WSH as follows:

<p>
$ wsh -c /usr/brl/bin/tbsh # same as /usr/5bin/sh

<p>
Type "man wsh" for details.

<p>
To use mged on this machine

<p>
	1. Move the console window to the upper left position of the
	screen using the mouse menu options to the window manager.

<p>
	2. Mged files which have been created on an Iris, Sun, or Alliant
	all use the same floating point format as the 4d.

	3. type
		vacuum.brl.mil&gt; mged file.g
		with sgi as the display type.

<p>
	4. There are a few problems with the tedit and the text
	display of the solid in solid edit, which should get fixed shortly.

<p>
The frame buffer is a bit different.

<p>
	There are four (4) different frame buffer modes for the
	4d Workstation. They are:

<p>
	/dev/sgi0	Private Memory non lingering window
	/dev/sgi1	Shared Memory non lingering window
	/dev/sgi2	Private Memory lingering window
	/dev/sgi3	Shared Memory linger window

<p>
	Using private memory the image is not saved after the window
	goes away but allows for many different images to be placed on
	the screen without interference.

<p>
	Shared Memory allows for future reference to the image using
	utilities such as fb-rle, fbed, fbzoom, but there is a problem
	with manipulating multiple images on the screen.

<p>
	lingering windows will stay around until you log off the system
	or you kill the window. A menu button to exit the window is provided
	via the right most button on the mouse just attach to the window
	first....

<p>
A complete set of Documentation will be provided in the graphics lab
in the near future.

<p>
As of yet the file system is not being backed up by the operators.
So please save your files else where.

<p>
<hr>
Date:     Wed, 18 May 88 22:52:19 EDT
From:     Mike Muuss &lt;mike@BRL.ARPA&gt;

<p>
I just discovered that on the SGI 4-D, negative shifts on (at least)
variables declared "register unsigned" don't work.  It would appear that
perhaps such a shift is being interpreted as a large positive shift.
At any rate, the values always came up zero in the low byte.

<p>
I wouldn't ordinarily write code that does this sort of thing -- this
particular piece of code was something that somebody else had written
quite a while ago, and I just chose this evening to port it to the 4-D.
On the other hand, the VAX and the Gould and probably many other machines
all permit negative shifts, so this seems like something that other
folks may encounter.

<p>
K&R are silent on this point (ref: pages 44, 189).  No help there.
So, I'm not asking that this be fixed, just surfacing it as an issue for
others to watch out for.

<p>
The upshot of this is that CAT-FB (a port of Ron Natalie's ICAT program)
now runs on the 4D, and very quickly.  It takes TROFF output and "typesets"
it into the current framebuffer, using the vfont bitmaps.  Very nice
for making slides.
	-Mike
<hr>
Date:     Fri, 20 May 88 5:35:33 EDT
From:     Doug Gwyn (VLD/VMB) &lt;gwyn@BRL.ARPA&gt;

<p>
&gt; K&R are silent on this point (ref: pages 44, 189).

<p>
K&R second edition p.206:
	The result is undefined if the right operand is negative, ...
<hr>
Date:     Fri, 20 May 88 6:39:46 EDT
From:     Mike Muuss &lt;mike@BRL.ARPA&gt;

<p>
A neat trick to keep tabs on a batch RT run that is storing it's
image in a file is to run:

<p>
	tail +0f file.pix | pix-fb

<p>
This will keep the screen up to date as the picture is written into
the file!
	Best,
	 -Mike
<hr>
Date:     Fri, 20 May 88 8:01:20 EDT
From:     Mike Muuss &lt;mike@BRL.ARPA&gt;

<p>
Last evening, I talked to Paul Tanenbaum on the phone, and we exchanged
some E-mail.  Paul identified four key features in RTRAY that he wished
to have added:

<p>
1.  useair be turned on, at least w/ a command-line option
2.  vldray.ob = (regionid &gt; 0) ? regionid : -aircode
3.  outside air (i.e. vldray.ob = -1) whenever I'm not in anything else
4.  "paint" as in shotray(1V)

<p>
I deferred preparing the slides for my Boulder ARO talks until this weekend
(sigh), and took this past evening to work on these issues. All four
requests have been accomplished, to the best of my ability to test them
(ie, not much testing yet). Here are some details:

<p>
1)  All the RT programs now have a -U flag to set the use_air flag.
It takes a boolean argument, so -U0 turns air use off, and -U1 turns air
use on.  All the RT family defaults to -U0, except for RTRAY, which
defaults to -U1.

<p>
2)  This rule has been implemented within librt(3), and reg_aircode
no longer exists -- because it has been folded into reg_regionid value,
with negative ID codes indicating air.  This actually helpped simplify
some of the librt code slightly, so it was an all-around win.

<p>
3&4)  Paul described to me what he called the VLD standard paint and
air codes, which I have implemented. The ``ob'' field of the ray(5V)
file is set to the region id of each intersected region, or to the
negative of the aircode for each air region, or to one of five
VLD-standard reserved values:

<p>
-999	zero-thickness ``paint'' at ray's first entry into the model.
-998	zero-thickness ``paint'' at any ray's exit interior to the model RPP.
-1	(unmodeled) air between modeled regions.
-997	zero-thickness ``paint'' at any ray's entry interior to the model RPP.
-996	zero-thickness ``paint'' at ray's final exit from the model.

<p>
In addition, as I described a few days ago, the ``rt'' (ray tag) field
of the ray(5V) file is a 32-bit value set to a combination of the grid X
and grid Y coordinates, plus the recursion/iteration (a_level) value
(used mostly for multibounce effects in radar simulation). This allows
all ray(5V) records pertaining to the same grid cell to be identified.

<p>
The new code and updated manual pages have been installed on VMB and VIM
in /usr/brlcad/bin (the usual place).  RDIST should propagate them to
the rest of the machines.  Run "man rtray" for additional details.

<p>
I there are problems with what has been implemented so far, please
let me know right away, and I'll work on them Friday night. Hopefully
there won't be any additional features required until I return from TDY.

<p>
	Best,
	 -Mike
<hr>
Date:     Wed, 18 May 88 11:54:31 EDT
From:     Paul Tanenbaum &lt;pjt@BRL.ARPA&gt;

<p>
I agree entirely with Doug:

<p>
    + Outside air is not required on a shotline before anything else is hit, or
      after the last component.  But, if for instance I come from the side and
      hit, say, road wheel, space, hull side, I'd like to have that space show
      up (automatically) as outside air.

    + The option of paint as implemented in shotray(1V) should serve our
      purposes admirably.

    + I don't see why we would need both regionid and aircode, IF we could get
      by with the convention that non-positive regionid were air.  I don't even
      see why the sign of the regionid need be the characteristic to use in
      distinguishing air.  But some convention across target descriptions and
      software is strongly desirable.

<p>
Now, as far as Gary's protestations against the violation of his sacred ideal
of *clean* code, I have several comments:

<p>
     First of all, talking about any of these things as "special case kludges"
glommed onto a hapless GIFT ignores history.  The &lt;only&gt; reason GIFT was built
was to provide target data for vulnerability computations.  Munitions versus
vehicles.  No CAD, or signature work, and not even terribly pretty pictures.
GIFT has served quite faithfully for a long time, and it even provided a basis
for a lot of subsequent *clean* code intended for broader applicability.

<p>
     Furthermore, I don't think the three suggestions I made qualify at all as
kludges.  A ray-generating routine that ignores air is no less fluky to my mind
than one that decides to report everything but the diesel fuel.

<p>
    Now the good news, Gary.  That scourge of conscientious software engineers
everywhere, Phantom Armor, need never rear its ugly head in ray(4V).  It was an
artifact of the way GIFT behaved.  Air is not treated like non-air in GIFT
shotlines.  Instead, every component has some amount (possibly 0) of air behind
it.  Thus, the only way to represent consecutive partitions with different
aircodes is to provide a dummy solid between them that acts as a bracket behind
which to hang the later air.  When air is handled explicitly in a ray(4V) file,
I don't need phantom armor to glue it to.

<p>
     +++paul
<hr>
Date:     Wed, 18 May 88 9:41:39 EDT
From:     Doug Gwyn (VLD/VMB) &lt;gwyn@BRL.ARPA&gt;

<p>
"Outside air" is often found in "target interiors".  It is defined
as the "background", i.e. it exists where nothing else in the model
is present.  Entering and exiting rays are not normally found in
RAY(4V) files.  I have found it useful to provide (either as an
option, or standardly) "exit paint" at the location of final exit
of a shot.  See SHOTRAY(1V) in the VLD/VMB UNIX Supplementary Manual
for more information.

<p>
I wouldn't check for non-negative region IDs.  There is no reason to
disallow explicitly modeled air regions.  In fact, with MGED I would
think that would be the right way to model compartments.
<hr>
Date:     Tue, 17 May 88 16:57:16 EDT
From:     Mike Muuss &lt;mike@BRL.ARPA&gt;

<p>
All perfectly reasonable requests.  Don't feel bad, remember that
rtray and rtshot were written to help me debug some stuff;  I documented
them and made them available in the hope that they would be worth
something to somebody else;  they were not particularly designed for V/L
work to start with.  I'm pleased that they are pretty close to what you
do need, and I appreciate your taking the time to clearly indicate
what you want.  That makes it easy to do something for you!

<p>
I have a question about the "outside air".  From the start point to first
hit point, I can invent an unmodeled air partition if that is helpful,
although I'm not clear on what purpose it might serve (I don't really
have to know, just curious).  However, after the LAST exit point,
does the outside air continue on to (a) the bounds of the model RPP,
or (b) +infinity?  Is the air ID of "-1", and the general practice
of making the region number the negative air code when in air
"the way" to do things?  Should code be inserted to verify that
all non-air regions have positive region IDs (there is presently no
such checking)?  What other assumptions should be wired in, and
what other checking should be done to allow new V/L work to go forward
with a minimum of baggage from the past, yet still supporting the
older codes without too much effort?
	Best,
	 -Mike

<p>
PS:  I suspect that further dialog should probably be limited to the
CAD list -- all of BRL Support probably does not care about raytracing.
<hr>
Date:     Tue, 17 May 88 16:02:17 EDT
From:     Paul Tanenbaum &lt;pjt@BRL.ARPA&gt;

<p>
     I have found several.  They are:

<p>
1)  The struct rt_i (as defined in raytrace.h) has a field

<p>
        int             useair;         /* "air" regions are used */

<p>
which is turned off.  Thus I never get any air in my ray files.  This is not
good.  Could it please be turned on, or at least provide a command-line option
to do so?  Paul Stay has already made me a version that does this, and it does
give me the air I need.

<p>
2)  Unfortunately, even with useair turned on, I don't get correct behavior.
Every flavor of air has a regionid of 0.  To differentiate between them, one
needs their aircodes.  So rtray should do something like

<p>
        #include "db.h"
        #include "ray.h"

<p>
        union record    rec;
        struct ray      vldray;

<p>
        if ((vldray.ob = rec.c.c_regionid) == 0)
            vldray.ob = -rec.c.c_aircode;

<p>
This way, if vldray.ob is positive, I'm dealing with some object, and if it's
non-positive, then I've got some kind of air (and I know what kind of air it
is, too).

<p>
3)  Finally, I also need "outside air."  This one I could probably fake by
enclosing the whole dumb target in an arb8 with aircode=1 and subtracting
everything from it, but it'd sure be nice if rtray did it for me.

<p>
     All three behaviors I've requested are standard procedure in the GIFT
world of business.  The principle of least surprise argues for making rtray
act that way to.

<p>
     By the way, I estimate that I'm making myself something of an annoyance
with all these requests, but they're essential to AMC's meeting a suspense to
DA on a project of extremely high priority.  I know that everyone is busy with
lots of work of his own, but this one plays right into a major systems analysis
effort.  And, on the bright side, once this shake-down cruise is completed, we
should possess a bug-free piece of software that goes a long way toward
integrating mged/rt and the Old School of V/L assessment.

<p>
     +++paul
<hr>
Date:     Tue, 17 May 88 5:50:46 EDT
From:     Mike Muuss &lt;mike@BRL.ARPA&gt;

<p>
This evening, I got a variety of software working on the SGI 4-D,
to enable running the Dunn instruments camera directly from the 4-D.
No big deal, but a lot of little nits had to be chased down,
including some more options to if_4d.c, bug fixes to dunnsnap
and dunncolor, and a new -F flag to dunnsnap (to open a shared memory
window before photographing the screen, natch).

<p>
On the 4-D, chars seem to be unsigned, which caused some difficulties
for "fblabel".

<p>
It's nice to finally have most of the software working on the 4-D.
	-Mike
<hr>
Date:     Sat, 21 May 88 9:18:04 EDT
From:     Mike Muuss &lt;mike@BRL.ARPA&gt;

<p>
I have taken Phil's ucolor and uline tools, and added them to the
util directory as plcolor and plline2, with a few minor improvements.
I needed these as part of the standard set of tools, to enable me
to do my performance plots on the SGI.
	-M
<hr>
Date:     Fri, 17 Jun 88 0:27:48 EDT
From:     Mike Muuss &lt;mike@BRL.ARPA&gt;

<p>
I have modified RT so that when it is run on UNIX systems, if the
output file already exists and has pixels in it, RT starts computing
with the first unfinished pixel, rather than starting over at the
beginning.

<p>
This is a valuable feature when machines are not staying up a lot.
	-Mike
<hr>
Date:     Fri, 17 Jun 88 2:08:26 EDT
From:     Phil Dykstra &lt;phil@BRL.ARPA&gt;

<p>
&gt; ... indeed, perhaps an xwindows version of brlcad would
&gt; get you over many of the problems inherent in maintaining
&gt; versions of the package for many different machines.

<p>
One of these days I should write a paper on the functional, design,
and philosophical differences between X and our frame buffer library.
I have written an X Window System interface for MGED and plan to do
so for the frame buffer library as well, but both of those interfaces
will for the most part have to be "substandard" interfaces.  While it
is true that the current Sun interfaces could (and should) be much
improved, they too will never be able to completely overcome insufficient
hardware support (at least on current Sun hardware).  X, while a very
nice thing indeed, was simply not designed to allow the level of
functionality at the level of performance that we desired.

<p>
The model of a frame buffer used in the library is one with dedicated
display memory, 24bit color, color maps, hardware pan and zoom, and
hardware cursor support.  When forced to work with a device without
some of these features, we have attempted to compensate for it in
software, with such things as shared memory for reattachable image
store, software pan and zoom imitation, etc.

<p>
The ideal hardware for the vector (MGED) interface is one with very
high vector drawing rates, color, double buffering (assuming a raster
display), hardware support of full 4x4 matrix transformations, knob
button and pen or mouse input devices.

<p>
It is ironic that probably the most widely used hardware with BRL-CAD
is Sun workstations, yet the Suns are the least appropriate machines
that we support.  We almost never run any of the graphical routines
(MGED or frame buffer tools) on the Suns - one of the reasons we have
worked so little on that interface.

<p>
You really need a full function frame buffer like an Ikonas, and a
full function graphics engine like an SGI, (and a nice terminal like
a Sun), in order to see our software in a reasonable light.

<p>
[I note for the record that X will become a more reasonable platform now
that folks with real graphics hardware like SGI have begun supporting
it.  You need good hardware for good graphics.  Software can't do it all.]

<p>
- Phil

<p>
ps: please don't think that I'm criticizing anything that you said,
    I just used it as a springboard for the above babbling.]
<hr>
Date:     Thu, 16 Jun 88 3:50:10 EDT
From:     Mike Muuss &lt;mike@BRL.ARPA&gt;

<p>
Tom,

<p>
I have incoporated your marble.c and solid texture routines (which I
named stxt.c) into the master copy of the CAD sources in
spark:/m/cad/rt -- if you plan to do additional work on them,
I'd appreciate it if you would check out copies from SPARK, and
proceed from there.  I didn't change anything, but I did add some
headers and fiddle a comment or two.

<p>
I have not had a chance to try them out, but I'm looking forward to it!
	Best,
	 -Mike
<hr>
Date:     Thu, 14 Jul 88 21:19:11 EDT
From:     Mike Muuss &lt;mike@BRL.ARPA&gt;

<p>
After further discussions with Gary on Wednesday, he persuaded me to
decouple the "VLD ray file object code encoding" from the behavior of
librt w.r.t. the handling of air codes.  I have implemented this change,
and taken care of the subsequent few modifications to rtray to cope.

<p>
Therefore, RIP and other codes will NOT need to be changed when used
with the new librt (when it is released).

<p>
Note that these changes have been applied to the experimental version
of the code on SPARK;  no production code has been changed yet.
However, having resolved this issue means that we should be well positioned
for placing the new librt into production within the next week or two,
which will start of the first cycle of integration testing for
Release 3.0.

<p>
I thank everybody for their input, understanding, and patience.

<p>
	Best,
	 -Mike
<hr>
Date:     Fri, 15 Jul 88 19:39:10 EDT
From:     Phil Dykstra &lt;phil@BRL.ARPA&gt;

<p>
Ed Davisson came up with a better way of finding bounding planes on a
torus.  Previously, I had fit bounding planes to a "hockey-puck" shaped
cylinder around the torus to avoid the quartic equations that would
result from the general case.  On non axis aligned tori this would
over estimate the bounds by at worst 41% of r2 (the smaller radii of
the torus); in the axis aligned case the estimate is exact.

<p>
Ed's method is strictly algebraic and gives exact answers for circular
tori (the only ones we can presently handle anyway).  I coded it up
in LIBRT this evening, chose a couple of "random" tori, and got the
following almost-meaningless-statistics-of-the-day:

<p>
	Pruning efficiency increased from 61% to 80%.
	Total run time went down by 5.5%.

<p>
Your mileage will vary.
Thanks Ed.

<p>
- Phil
<hr>
Date:     Wed, 20 Jul 88 23:26:27 EDT
From:     Phil Dykstra &lt;phil@BRL.ARPA&gt;

<p>
A couple of days ago I added a new pseudo device to libfb called stack.
I the spirit of rt's shader by the same name, stack takes a semicolon
separated list of framebuffer specs and send a copy of all output
to each one.  Input comes from the first device.

<p>
e.g.

<p>
	setenv FB_FILE '/dev/stack /dev/ik0;/dev/debug;'

<p>
to use ik0 but also dump a debug trace.  Or perhaps

<p>
	setenv FB_FILE '/dev/stack filename;host:device;'

<p>
to keep a file copy of the frame buffer image on the local machine.
Good perhaps for demos when you want to string an arbitrary number
of displays together.  To appear in 3.0.

<p>
- Phil
<hr>
Date: Wed, 20 Jul 88 15:18:57 PDT
From: Alex Woo &lt;woo@pioneer.arc.nasa.gov&gt;

<p>
In general the Q matrix is not diagonal, but it is with respect to the
principle directions.  (The notation is Do Carmo is pretty much standard.)
What Andy calls the curvature matrix on p.67 (10.10) is what Do Carmo
calls the (aij) matrix on page 155.  This matrix is actually computed
in spl_curve.

<p>
You ask if we really need II.  Actually not if we have both principle
directions.  You can always conjugate the diagonal Q by a change of basis back
to the global or local coordinate system.  This can be done if both
principle directions are known.

<p>
I would think that your modification to the curvature structure is enough.
I personally prefer k1, k2 as principle curvatures rather than c1 and c2.

<p>
Did Andy send you a copy of Ri-Chee's thesis as well?  The divergence
equations on p48-49 are what we need to solve.

<p>
Alex

<p>
P.S.  What application actually uses the curvature structure?  Has you tried
this application on splined solids?  Like the teapot?  We can send some
simple spline objects like cone-spheres or toy jets if you would like.

<p>
(We usually use algebraic coefficients or hermite basis for our splines.)
<hr>
Date:     Thu, 21 Jul 88 0:41:27 EDT
From:     Phil Dykstra &lt;phil@BRL.ARPA&gt;

<p>
&gt; In general the Q matrix is not diagonal, but it is with respect to the
&gt; principle directions.  (The notation is Do Carmo is pretty much standard.)
&gt; What Andy calls the curvature matrix on p.67 (10.10) is what Do Carmo
&gt; calls the (aij) matrix on page 155.  This matrix is actually computed
&gt; in spl_curve.

<p>
Agree.  Less a sign difference and an a12 &lt;-&gt; a21 swap (at least w.r.t.
Andy's paper).  I don't have a copy of Do Carmo.  Paul Stay and Peter
Stiller worked out the formulas in spl_curve.  Paul probably has them
on paper.

<p>
&gt; You ask if we really need II.  Actually not if we have both principle
&gt; directions.  You can always conjugate the diagonal Q by a change of basis
&gt; back to the global or local coordinate system.  This can be done if both
&gt; principle directions are known.

<p>
You always had pdir2 via: VCROSS( pdir2, normal, pdir1 ), i.e.
pdir2 = normal x pdir1.  Right?  I think we might as well return
it in the curvature structure though.

<p>
&gt; Did Andy send you a copy of Ri-Chee's thesis as well?  The divergence
&gt; equations on p48-49 are what we need to solve.

<p>
No, but I would love to get a copy.  I was working from T.B.A. Senior's
paper on divergence factors (which use trig formulas based on the
principle curvatures, not the full Q or II matrix).

<p>
&gt; P.S.  What application actually uses the curvature structure?  Has you
&gt; tried this application on splined solids?  Like the teapot?

<p>
We have tried the Teapot with my SAR code, and as I recall spline
curvature was causing some problems.  Paul has done a fair amount of
work on the splines since that time though, but I don't think that we
have checked them out since then.  You are the first person besides
"us" that has wanted curvature!  So, its good that you bring the
spline curvature issue back up.  I just hope you don't mind being
a test case.

<p>
- Phil
<hr>
Date: Wed, 20 Jul 88 11:44:03 PDT
From: Alex Woo &lt;woo@pioneer.arc.nasa.gov&gt;

<p>
Thanks for a copy of Ed's paper on Curvatures in MGED but I'm afraid that
I am still very confused by the code in /librt/spline.c.  Here is the
offending section:

<p>

<p>
	denom = ( (E*G) - (F*F) );

<p>
	a11 = (( f * F ) -  (e * G) ) / denom;

<p>
	a21 = ((e*F) - (f * E))/ denom;

<p>
	a12 = ((g * F) - (f * G))/ denom;

<p>
	a22 = ((f * F) - (g * E))/ denom;

<p>
	a = 1.0;
	b = - ( a11 +  a22);
	c = (a11 * a22) - (a12 * a21);

<p>
	rt_orthovec( uvec, hitp-&gt;hit_normal );
	VCROSS( vvec, hitp-&gt;hit_normal, uvec );

<p>
	eigen2x2( &cvp-&gt;crv_c1, &cvp-&gt;crv_c2, vec1, vec2, a, b, c );
	VCOMB2( cvp-&gt;crv_pdir, vec1[X], uvec, vec1[Y], vvec );
	VUNITIZE( cvp-&gt;crv_pdir );

<p>

<p>
It would seem to me that the trace = 2*mean curvature and the determinant=
Gaussian curvative are invariant.  The a,b,c transformation above does
not respect this invariance.  Since the coordinates from a parametric
spline surface are not necessarily orthogonal, the matrix of DN_p is
not necessarily symmetric.  Unless the e,f,g,E,F,and G are not the
standard notation found in DoCarmo, then I think that the direction vector
and curvatures produced by eigen2x2 above are not correct???

<p>
Please let me know if these comments are in left field, but it would be
fairly easy to compute the curvatures and principle directions from the
a11,a12,a21,a22 above.

<p>
Alex Woo
woo@pioneer.arc.nasa.gov
<hr>
Date:     Wed, 20 Jul 88 16:42:18 EDT
From:     Phil Dykstra &lt;phil@BRL.ARPA&gt;

<p>
For starters let me say that we probably can change the curvature call and
structure if need be.  I believe that I am the only person with code that
uses it at the moment.  We can check.

<p>
Two, I just noticed that the comment above the curvature structure in
raytrace.h is wrong.  The sign convention was changed and this comment
wasn't.  It also might be worth while adding the other principle
direction vector, since it is usually computed and if needed it would
save the user from computing it all over again.  Thus raytrace.h
should probably look like:

<p>
/*
 *  Information about curvature of the surface at a hit point.
 *  The principal direction pdir1 has unit length and principal curvature c1.
 *  |c1| &lt;= |c2|, i.e. c1 is the most nearly flat principle curvature.
 *  A POSITIVE curvature indicates that the surface bends TOWARD the
 *  (outward pointing) normal vector at that point.
 *  c1 and c2 are the inverse radii of curvature.
 *  pdir2 = normal x pdir1.
 */
struct curvature {
	vect_t		crv_pdir1;	/* Principle direction */
	fastf_t		crv_c1;		/* curvature in principle dir */
	vect_t		crv_pdir2;	/* other principle direction */
	fastf_t		crv_c2;		/* curvature in other direction */
};

<p>
Perhaps c1, c2 should be k1, k2 per common notation, I dunno.  I should
probably sample the waters via the CAD list to see if anyone else uses
curvature yet!

<p>
Okay, now to your note:

<p>
&gt; I would like to modify these routines and return the second
&gt; fundamental form (structure II).

<p>
Just to get my terms straight (I just got Andy Lee's GTD manuscript
two days ago so at least now I know what a "Q" curvature matrix is!),
the curvature matrix Q can be found from the above information by:

<p>
	    [ c1  0 ]
	Q = [       ]
	    [ 0  c2 ]

<p>
The first fundamental matrix I, and the second fundamental matrix II,
are related by Q via:

<p>
	II = Q I

<p>
So to find II, we need I (which consists of the partials of the
basis vectors dotted together).  Its not clear to me that we have
the needed information.  I also note that in some cases, i.e. torus,
we compute the curvatures and directions geometrically, rather than
from the second fundamental form.  I have formulas for the latter,
but the former is more efficient.

<p>
So a couple of questions:

<p>
You say that you want II.  What do you need in II that you can't get
from Q?  Just curious.

<p>
&gt; In ell_curve, tgc_curve and spl_curve, you appear to compute the trace
&gt; and determinant of the second fundamental form ....

<p>
Are you saying that what you need is already in there, just not
returned?  I have no objections to changing any of this code, I
just want to understand exactly what information is needed.

<p>
- Phil
<hr>
Date:     Sat, 23 Jul 88 0:48:22 EDT
From:     Paul H Deitz - Chief VMB/VLD &lt;phd@BRL.ARPA&gt;

<p>
	Mike took the liberty to forward your comments about BRL-CAD
to me.  I found them interesting and would like to be privy to your
discussions with Mike.

<p>
	Probably more than Mike, I have attempted to carry the flag into
some classic meeting grounds which typically advertise an interest in
CAD, CAE and sometimes CAM and CIM.  In thinking about this experience
I found the following dates from my back electronic calendars in which
I have presented papers to groups with direct industry representation.

<p>
-------------------
  05/18-20/82			JTCG/AS Meeting at Wright-Pat
  06/13-16/82			NCGA: Anaheim, CA
Wed 10/20/82			PHD in Phoenix to give MTAG paper
  10/12-14/83	Wash. DC	Defense Computers-Graphics'83
				Computer Graphics Conf: Wash Conv Center
Mon 03/26/84	0900		Presentation at McCormick Place (ASME)
Wed 11/28/84	0930		Paper @ CAD/CAM MTAG Symposium - Seattle
Wed 05/14/86	0845		FMC Presentation: San Jose Hyatt
Tue 08/25/87	1300	DC	JTCG Mtg: PHD Presentation @ Center for
					Naval Analysis
Wed 09/30/87	0900	DC	PHD Presentation at Defense & Government
				Computer Graphics Conf: Wash Conv Center
Wed 05/11/88	-	-	ADPA Mtg: San Diego: Day #2
-------------------

<p>
Back in the 83-84 time frame, I also had extensive interaction with
the DARCOM Office of Manufacturing Technology (OMT) and Rock Island
Industrial Based Engineering Activity (IBEA).

<p>
Let me summarize briefly.

<p>
o First Commercial CAD Capabilities:  This has probably changed a bit,
  but the commercial sector generally was interested in generating an
  electronic data base of a part/item/etc., turning this data base into
  a 3-D mesh for structural analysis, and also generating blue prints.
  Note that in general, analysis meant structural analysis.  Few of
  the modelers were solid geometric modelers and, until a few years ago,
  absolutely none could even possibly model systems of the number of
  parts that we require today in, say, an M1A1 or Bradley description.
  Even today there may not be a commerical system that can match this
  requirement.

<p>
o CAD for the Army was under OMT (which I suspect is defunct).  And all
  OMT cared about was manufacturing problems.

<p>
o Having worked hard to establish common ground between the early threads
  of BRL-CAD and the commercial market place, I found a disappointingly
  small intersection.  Note for example, in 1984 I spoke by invitation
  at the ASME meeting in Chicago.  Typically the audience at such meetings
  is made up of folks who want to design electric drills without paper.
  Usually few if any of these folks were interested in the very broad
  class of military problems those in SECAD and VLD care about.

<p>
o On the other hand, BRL-CAD has found a very large market which is growing
  very quickly.  It is generally not with people who have classically
  associated with CAD/CAM, but with another very large group of people
  who are interested in performing item-level analyses of military equipment.
  That includes all kinds of topics from vulnerability to signatures, to
  weights, neutron transport, high-power microwave damage, . . .   The fact
  that the BRL-CAD software distribution has now reached 350 sites is
  testament to that need.

<p>
Monday I'll send you a couple of papers which illustrate what we typically
do with what we call CAD and analysis.

<p>
Am looking forward to your views on this all.

<p>
Best,
phd
<hr>
Date:     Fri, 22 Jul 88 20:08:36 EDT
From:     Mike Muuss  &lt;mike@brl.arpa&gt;

<p>
Thanks for your nice note about my paper and the BRL-CAD Package.
If it should happen that you are able to use the BRL-CAD software to
assist you in some of your work, I would be most pleased.

<p>
TOPIC 1:  Computer Aided Design

<p>
Please understand that I am not in the business of "selling" the BRL-CAD
software.  We distribute it in the hopes that it will be useful to
others, but we accrue no benefits from having other people use it, so
there certainly is no compulsion for anybody outside BRL/VLD to use it.

<p>
Every few years, BRL/VLD has conducted a market survey of commerical
CAD systems, in an attempt to switch to using commercial software,
rather than having to develope it locally.  Unfortunately, on every
market survey, the complex analysis demands of the BRL/VLD mission could
not be satisfied by commercial software. Therefore, BRL has been forced
to remain active the in CAD software field.

<p>
The roots of the BRL-CAD Package date back to 1958, with early work by
the VLD folks in solid modeling and ray-tracing.  The present software
represents the third generation of this capability.  The strategy has
always been to focus on providing capabilities that BRL/VLD has required
that were not available in commercial packages, while avoiding spending
effort duplicating capabilities that are well supported in the commercial
community.  This strategy has positioned the BRL-CAD Package in a special
"niche" which many people do not fully appreciate.  Outside evaulations
of our package have assessed the BRL-CAD Package as being as much as
five years ahead of commercial packages, **in certain areas only**.

<p>
For example, the BRL-CAD Package does not presently have the ability
to produce annotated engineering drawings, and, although VLD does have a
contractor working on adding this capability, it will probably be over a
year before this is in the hands of the user community.

<p>
On the other hand, the range of engineering assessments that can be
performed on complex 3-D geometry using the BRL-CAD Package is quite
wide. It is a testimony to the quality of the underlying geometric
representation that new analysis applications continue to be built, very
quickly, and with only modest effort.

<p>
In your message, you wrote:

<p>
&gt;&gt; The problem that I see is that BRL-CAD is not what engineers commonly
&gt;&gt; call CAD.  It doesn't do the traditional "design" kinds of things that
&gt;&gt; all of the commercial CAD packages do.  It does do things that the
&gt;&gt; commercial CAD packages can only hope to do in the future.

<p>
I would like to suggest that the difference you have noted, rather than
being a "problem", is our success -- it is a result of having built
a software package that allows us to tackle problems that can not be
done any other way.  This cutting-edge capability is our "value added"
-- the reason that BRL is in the CAD business at all.

<p>
For example, Kurt Fickie can use the BRL-CAD Package to combine 3-D
solid geometry, vector flow fields from analytic computations, and
digitized photographic data from laboratory experiments.  These three
types of information exist within the single framework of the BRL-CAD
package, to produce images that show the relationship between the models
and the experiments.  This is one example of the sort of analysis
capabilities that do not, to my knowledge, exist in commercially
available packages.

<p>
There are a great many things that the BRL-CAD Package does NOT do, and
I try to be very frank in informing potential users of those areas.
However, at the same time, there are lots of problems that the BRL-CAD
Package seems to do particularly well.  There are now over 300 sites
that have copies of our software, several dozen of which have committed
very heavily to it.

<p>
The BRL-CAD software is a central part of the engineering "design loop",
and across all of the organizations that use the BRL-CAD software, it is
used for creating and optimizing the designs of a great variety of
items. Within BRL/VLD, it is used to design, analyze, assess, and
optimize all ground vehicles in the U. S. Army.  At the same time, it is
also used to drive the design of new radar and sensor systems, and to
help evaluate the benefits of various signature reduction measures.
Outside BRL/VLD, it finds significant use, with the Army Engineer's
Topographic Laboratory using it for terrain studies, etc, etc. It is
used at Northrop for various stages of aircraft design and evaluation,
and also in their "factory of the future" project, to provide the
coupling between their existing drafting-based CAD systems and their
computer-vision system that supervises their (experimental) robotic
factory. In the University sector, it is used for visualizing medical
data, teaching Naval Architecture, and a great variety of other tasks.
There is even a group in Europe that is using BRL-CAD for the design
of optimized sawmills!

<p>
Also, a group totally outside BRL, in the Joint Intelligence community,
after a two year long market survey by a team of about 40 experts (hired
for the occasion from Universities, Industry, and Government Agencies),
have selected the BRL-CAD Package as the single platform to be used for
all INTEL signature modeling. I consider this to be a very significant
"vote of confidence" in the quality and capability of our software.

<p>
One of the very special aspects of the BRL-CAD Package is that we
distribute the complete source code to the system. Sophisticated users
who wish to add discipline-specific features, or wish to couple new
kinds of analysis codes to the capabilities that already exist within
the BRL-CAD system, can do so without impediment.

<p>
I would be pleased to chat with you about your particular application,
to help you decide if the BRL-CAD software is likely to be a "good fit",
or whether there may be other alternatives that might serve your needs better.

<p>
TOPIC 2:  Vendor Assessments and Future Directions

<p>
The Advanced Computer Systems Team (ACST) spends about 6-8 weeks a year
engaged in keeping up to date with computer hardware vendor plans,
not only for the present, but also to track (and sometimes steer) their
plans for the 2-3 year time frame.  There certainly are a lot of
vendors, and there are always a few that we do not have full status on,
but I feel that we do an excellent job of covering futures. We also
invest a certain amount of time in conducting benchmarks of these
different machines, to be certain that we have a performance assessment
which is solid.  In our benchmarking, we have generally found the
results of the Whetstone, LINPACK, and BRL-CAD tests to be strongly
correlated, but we always insist on running all three.

<p>
ACST performs this market evaluation and benchmarking function to
advise SECAD and VLD on how to position themselves to derive maximum
price/performance benefit **on SECAD & VLD computational problems** when
purchasing new computers.

<p>
In the case of the particular vendors that you mentioned (Alliant, Convex,
Multiflow), I have had the pleasure of spending several days each with the
main processor designers for these companies, and I feel that I have a
very good handle on where they are now, and where they are likely to be
in several years.  Our non-disclosure agreements prevent discussing details
in this forum.

<p>
Perhaps when we get together, we can exchange design information about
various systems, as you probably have information on some systems that I
have not yet had the opportunity to study in detail.

<p>
TOPIC 3:  Conferences

<p>
In the first week in August, all of ACST will be attending SIGGRAPH,
the world's main conference concerning research activity in computer
graphics and geometric modeling.  I regret that we will be unable to
send anyone to the more applications oriented ASME Computers in
Engineering conference.

<p>
Fortunately, SIGGRAPH also has a superb vendor show, which we will
attend.  As of 1-March-88, there were over 250 vendors already
registered for the SIGGRAPH exhibition. It sounds to me like we should
get together after our respective conferences, and compare notes on the
latest unveilings!

<p>
SUMMARY

<p>
I'm looking forward to a chance to get together, to get to know you
better, and to share with you some of ACST's recent work.  Looking
at my calendar, just about any afternoon from 11-Aug onward would be fine.
Do you have a preference for a date?

<p>
	Best,
	 -Mike
<hr>
Date: Mon, 18 Jul 88 14:01:11 PDT
From: Alex Woo &lt;woo@pioneer.arc.nasa.gov&gt;

<p>
In ell_curve, tgc_curve and spl_curve, you appear to compute the trace
and determinant of the second fundamental form and return the curvature
structure.  I would like to modify these routines and return the second
fundamental form (structure II).  For compatibility, I think that I should
make new routines and add an entirely new structure to raytrace.h.
It would be nice if your group concurred with this decision and included
these things in your subsequent releases.  Any comments?  Concurrence?

<p>
Do you have any notes on the various xxx_curve functions?  I suppose I can
back it the equations out of the code but some notes would be helpful.
For splines, there doesn't appear to be any need for changes to spl_curve
except for returning the form structure II.

<p>
Alex Woo

<p>
P.S.  Can you send me a sample spline solid in asci form?  There doesn't
appear to be any in the sample databases.  (I have been reading the IGES
manual for entities 114 and 126.  Your spline format is closest to the 126
format for NURB's.  Unfortunately we have been using the simpler 114 format
for bicubics.  Also, IGES, version 4.0 supports CSG entities.)
<hr>
Date: 7 Jan 88 16:44:00 GMT
From: Michael Mascagni &lt;mascagni@nyu-acf4.arpa&gt;

<p>
I have gotten the RGB &lt;-&gt; XYZ transformation information for the Iris
4D/60T monitor.  It is:

<p>
      R         G         B
X  0.6100    0.2980    0.1510
Y  0.3420    0.5880    0.0640
Z  0.0480    0.1240    0.7850

<p>
      X         Y         Z
R  2.2708   -1.0772   -0.3490 multiply the XYZ values of the color you want
G -1.3285    2.3607    0.0631 by this matrix for the RGB (not normalized)
B  0.0710   -0.3070    1.2853 values for the 4D/60T monitor.

<p>
                       Have a colorful experience today,

<p>
                       Michael Mascagni mascagni@nyu.edu
                                        mascagni@ncifcrf.gov
<hr>
Date:     Mon, 25 Jan 88 9:24:41 EST
From:     Charlie Arnold (ERIM - Davisson) &lt;carnold@BRL.ARPA&gt;

<p>

	     There are some people here looking into ground clutter.
	The following references will give an idea of what models they
	are considering.

		1. M. Borgeaud, R.T. Shin, and J.A. Kong, "Theoretical
		   Models for Polarimetric Radar Clutter", Journal of
		   E.M. Waves and App., pp73-89, Jan 1987.
		2. A.K.Fung, H.J. Eom, "Multiple Scattering and Depolarization
		   by a Randomly Rough Kirchhoff Surface", IEEE Trans. Ant.
		   and Prop., pp. 463-471, May 1981.
		3. F.T. Ulaby, A.K. Fung, R.K. Moore (1982), Microwave
		   Remote Sensing, Addison-Wesley, Mass., chap. 12
		4. G.R. Valenzuela, "Depolarization of EM waves by Slightly
		   Rough Surfaces", IEEE Trans. Ant. and Prop., pp. 552-557,
		   July 1967.

	I am working on sending you some internal memos on finite impedance
	surfaces. I need to clear this with the author's first so it may take
	a few more days.

				Charlie Arnold
<hr>
Date:     Wed, 3 Feb 88 2:18:42 EST
From:     Mike Muuss &lt;mike@BRL.ARPA&gt;

<p>
Phil mentioned to me that Tom wanted to take a videotape with him
to some conference on Monday.  Right now we are rather short on
videotape -- we have 5 reels, all borrowed from IBD.  We have one
that isn't being used yet, so we can get started, but having more
tape around is a must.  They are stocked at the self-service
supply store (Piggly Wiggly), so getting a case or two shouldn't
be a problem.

<p>
Also, having a second VTR would be very handy, so that we could
duplicate tapes as needed, although the A/V folks have a well
equipped TV studio that I'm sure we can call on, too.

<p>
The video tape that we need is standard professional 3/4" U-matic
videocasette format.  Any one of three types will work, I list them
in order of preference:

<p>
1)  Any "KSP-S" and "KSP" series tape would be preferred.  20 minute
lengths would be best, 60 minutes is also OK.  Ie, KSP-S-20 or KSP-20.

<p>
2)  The only tape that still has it's stock sticker is
Ampex 187 tape, style KCA-60.  It has stock numbers:
	5836010294285
	FSCM 088068 MFR/PN 187KCA60C
	TAPE, videocassette
	1 EACH
	F04606-86-C-0152
	A 2/86

<p>
3)  A slightly less desirable tape is Ampex 197 BCA-20.

<p>
	Thanks!
	 -Mike
<hr>
Date:     Thu, 24 Mar 88 8:51:46 EST
From:     "David F. Rogers" &lt;dfr@USNA.MIL&gt;

<p>
Why not try weighted averaging post-filtering using a Bartlett filter.
For details see

<p>
Crow, Frank, c. "A comparison of Antialiasing Techniques," IEEE CG & A,
Vol. 1, pp 40-47, 1981

<p>
or

<p>
Rogers, D. F. Procedural Elements for Computer Graphics pp 93-95.

<p>
<hr>
Date:    27 Mar 88 20:29:11 GMT
From:    umix!oxtrap!rich@uunet.uu.net (K. Richard Magill)

<p>
&gt;   ...can anyone tell me how to extract from a 1/4 inch cartridge,
&gt;   written on a MASSCOMP, from a SUN??  I had no trouble whatsoever
&gt;   reading and writing tapes between Masscomp and Intel machines, but
&gt;   am unable to read the tape on a Sun.  Any ideas??

<p>
Yes.  Use /dev/rst8.  I've passed a number of tapes from burroughs xe550,
(really a ct megaframe), masscomp, sun, sequent, tower, apollo, etc.
Nearly everyone, (except 3b2's which use a different encoding), uses QIC
24 as their default.

<p>
Sun uses QIC 11, (/dev/rst0), for distributions, although I can't see why,
but they do provide QIC 24 in the form of /dev/rst8.  (man 4 st).

<p>
Some machines, (some towers), byteswap the tar/cpio archive so you have to
dd swab them off the tape.  Ansii headers are a pain for unix.  tar is the
easiest format, (what with pd-tar and all).

<p>
Two hints...  Remember to retension the tape *prior* to using it on a new
drive.  Some drivers do this every time you load a tape, others only on
request.  (man 1 mt).  Also, you can't just cat from one drive to another
to copy tapes.  (buffer sizes, I'm told, I don't have source).  Instead,
you must dd (man 1 dd) them and if you machine swabs, it's anybody's guess
what the output byte ordering will be.

<p>
<hr>
Date:     Wed, 27 Apr 88 9:08:32 EDT
From:     "Gary S. Moss" (VLD/VMB) &lt;moss@BRL.ARPA&gt;

<p>
	If you need to illuminate an object from the keyboard, type:
mged&gt; press oill
mged&gt; ill &lt;name&gt;

<p>
	Its much easier to use the mouse to select the pull down menus,
then select &lt;object illuminate&gt; or press the &lt;object illuminate&gt; button
on your button box, then move the mouse vertically on the pad to select
the object.  The keyboard &lt;press&gt; command and &lt;ill&gt; are there mainly for
Tektronix or other less brain-damaged hardware that don't happen to have
button boxes or mouses (*most* button functions can be done with the
mouse).

<p>
~moss

<p>
<hr>
Date:     Wed, 25 May 88 3:48:59 EDT
From:     Mike Muuss &lt;mike@BRL.ARPA&gt;

<p>
I would like to briefly recapitulate the "rtray" events, so that BRL folks
can gain additional understanding, and so that non-BRL folks on the CAD
list can understand how the scale of the BRL environment can occasionally
lead to oscilation.

<p>
PJT had a high-priority request for the addition of features to RTRAY.
They were needed within one day, and over the course of several hours
that evening, he and I worked out some of the knotty details (did his
codes expect the surface normals on air to point outward, like
everything else, or inward?, etc, etc).  PJT also described to me in
great detail the "Doug Gwyn Approved VLD Standard" handling of air and
paint in VLD-standard ray(5V) files, and suggested that it would be best
if the "regionid" and "aircode" numbers from the MGED database were
combined within LIBRT using the VLD Standard procedure.  I had no
preference, and decided to consider the possibility, since VLD are
the folks who care about aircodes -- might was well conform to their
standard.

<p>
I coded until 4 AM.  One of the small issues to be decided was the
handling of the air code.  It had not been seriously addressed
previously as an issue.  The declaration in raytrace.h read:

<p>
        short           reg_aircode;    /* ?? */

<p>
signifying it's uncertain status, but the value was copied in religiously
from the MGED database, and the overlap checker in LIBRT did use this
value.  Concerned about possible compatability issues, I executed these
commands:

<p>
	cd /m/cad
	fgrep reg_aircode */*.[hc]

<p>
These commands swept the entire R&D CAD source tree for use of this symbol.
There was one "hit", a printf() call in LGT.  Because no installed CAD
Package software used this field in a significant way, and I was confident
that PJT had accurately portrayed the VLD Standard, I decided to proceed
with the modification.  Several vital points here:

<p>
1)  I did not go looking for source code that was not part of the installed
CAD PAckage software.  If I had happened across the RIP sources, I surely
would have implemented Moss' suggestion directly (more on this below).
We might profit from some contemplation about the different groups,
and how they manage their source code here.  I have several good explanations
why I didn't examine the various VLD sources, but it was mostly due to being
rushed and tired.  If there is any blame to be placed in this whole
sequence of events, this is the place, and I'll take the blame.
2)  I notified Moss via E-mail about the impact on LGT, with a suggested fix.
3)  The source code was modified in the "R&D" tree only.
4)  I recompiled all of the relevant CAD software (except LGT, as noted
above) to ensure compatability with the change.

<p>
I tested the new RTRAY until about 0600, at which point I decided that
things were "good enough", generated production binaries of "rtray" and
"rtshot", installed just the binaries on VMB and VIM, **without doing a
"make install**, to satisfy PJT's need (carefully leaving older versions
as rtray.bak and rtshot.bak), wrote my E-mail reporting the work, and
went home to sleep.

<p>
Generaly, I would not have installed new binaries at this point.  However,
given that:

<p>
1)  This was a rush job, and
2)  There was not (yet) any other use of the RTRAY program,

<p>
this seemed the most effective way to get things into the hands of PJT
and the folks working with him. I felt confident that if there were any
hidden problems with this change, they would either surface:

<p>
1)  as PJT began using the software,
2)  as the R&D process continued, or
3)  at the next Integration and Test Cycle.

<p>
Let me elaborate on some of the subtle details hidden in all this:

<p>
Please recall that at any time, there are no fewer than three "current"
copies of the CAD software:

<p>
1)  The TAR archive of the current distribution relese (now Rel 2.3).
2)  The tree spark:/m/dist, which contains source code for the FORMALLY
    INSTALLED versions of the software (ie, that software which was
    installed by saying "make install" or "cake install").
3)  The tree spark:/m/cad, which is the development area.  The sources for
    the very latest software live here, and are under RCS (source code
    Revision Control System) archival control.  This is the "R&D" copy
    of the software, and is where all changes are made.

<p>
Copy #1 is always frozen, and changes only at the END of a full Integration
and Test cycle (more on this later).  Copy #2 is updated only when
new software is FORMALLY RELEASED from R&D status to Production status
for BRL internal use only (ie, "make install").  This happens several times
during an Integration and Test Cycle, and occasionally, as required,
at other times.

<p>
So far, the history of the BRL CAD Package has been such that a
Distribution Release has been produced once every 5-6 months.  Our goal
is to produce between one and two distributions a year, so I feel that
we have been doing very well. The formalism of the release cycle has
been in place for nearly two years now.  There are so many different
groups in BRL that have some interest in the CAD Package, but outside of
ACST, few people bother with worrying about all this formalism.  There
is a general tendency for folks to "ship code" whenever there is a need,
and worry about compatability later. Ironicly, they very concerns that
have been raised by the "fast response" to the RTRAY need.

<p>
All of this release formalism, like most technology, is a two edged
sword. On the advantage side, there is the fact that BRL CAD Release
tapes tend to be very well tested software, and virtually everything on
the tapes works on a wide variety of machines.  Problems experienced
with the softwrae on the release tapes generally stems either from:

<p>
1)  Errors in configuring or installing the software at a recipient site, or
2)  Bugs that exist also at BRL and have never been encountered before.

<p>
To address item #1, I can assure you that Release 3.0 will be
significantly easier to configure and install, partly thanks to the
power of CAKE, and partly because I have spent almost four days
improving the packaging. I take a great deal of pride in how effective
our testing cycle has been. We are not quite as good as some companies,
but we are better than probably 90% of them.

<p>
The negative side of this complex integration and test cycle is that
we are generally shipping code that is six months out of date, and
many requests for features get answered with a "we already did that --
wait for the next release" answer, which isn't always much comfort to
the person asking.

<p>
I have directed that nobody that works for ACST should distribute software
outside of the normal release cycle, except to our designated alpha-test
sites, or in case of serious need to meet a Government requirement.
The reason for this is that mixing software from different release versions,
or mixing released and unreleased software has the potential for difficulties.
There have been some non-ACST folks at BRL that have been distributing
chunks of software outside of the release cycle, and on several occasions,
the resulting incompatability problems have resulted in howls of anger
from the recipient.

<p>
Part of the complexity is being able to discern which recipients wish to
use this software as a nearly "turn key" package, and which ones are
also interested in the "insides", and could cope with the potential
complexity of mixing versions.  Because the number of people working
on the BRL CAD Package at BRL is smaller than the numer of people using
the BRL CAD Package at some single outside sites, and we have over 300
sites now, there isn't much time for site-specific attention.  "Mass
production" is the only way we can usually afford to handle things.
(In-government users, and relevant defense contractors, obviously
receive a higher level of service).

<p>
Returning from the philosophy lecture now, let me return to the
technical details.  Moss' original suggestion that the "reg_aircode"
field be re-instated, with its old semantics, and that the new
reg_regionid field remain in it's new form. This is exactly the strategy
that I had adopted when it was pointed out that there was an issue. I
did this over the weekend, but was too busy preparing slides for the
trip I'm leaving on in a few hours to describe it immediately. The
definition now reads:

<p>
        short           reg_regionid;   /* Region ID code.  +=solid, -=air */
        short           reg_aircode;    /* THIS FIELD CONSIDERED OBSOLETE */

<p>
so that old code will compile.  This definition, and the one line of
code to fill it in, are now checked in as the latest "R&D" version of the
code on SPARK in /m/cad.  No installed software has been changed,
and effectively, no other software should have to be changed (although
the keeper of RIP might want to add a check for negative reg_regionid
values).

<p>
Gary does make an interesting point in one of his subsequent letters
from Monday morning, where he points out that if he mixes a new version
of an application code which cares about Air with an old library,
or vice versa, then there will be problems.  This is more a problem with
the fact that Gary perfers to mix and match software, rather than
following the formalism of the software Integration and Test cycle,
but this should at least be thought about.

<p>
Anyways, I am open to further discussion about how to handle the
Air field.  If folks can persuade me that it makes more sense to have
two VLD-Standard ways of signifying air, then I'll gladly accomodate that.
As I said earlier, I don't have any personal use for the notion of Air,
so I don't feel very strongly about it.  On the other hand, after all this
chattering, I am most definitely NOT going to make a third change until
we have had a chance to get a whole bunch of VLD people together to talk
about it -- face to face.  Because I'm on TDY for 2 weeks, it will have
to keep until then.

<p>
One final point I would like to make.  Please note how at no time did
the format of the stored MGED database change, nor was there any reason
for it to change.  Whoever brought that up inserted a moby red herring
into the disucssion. I assure all of you that I consider database format
changes to be a "really big deal", and they will be done only for good
cause, and with lots of trumpet tooting in advance, so that we can enjoy
our usual vigorous debate before actually doing anything.

<p>
The electronic discussion of this topic is now closed.
	-Mike
<hr>
Date:     Fri, 3 Jun 88 9:47:29 EDT
From:     "Gary S. Moss" (VLD/VMB) &lt;moss@BRL.ARPA&gt;

<p>
Ian writes:
&gt;
&gt; 	I sent this letter two weeks ago,I am not sure whether it got to you
&gt; 	or if it got lost in the pipeline;anyway here goes again!
We got it, I was just hoping someone else would answer it since I only know
some of the answers, but here goes...
&gt; 	1. When trying to use the ARS command I get the reply
&gt; 		"not implemented yet",
&gt; 	we have version 2.1 (Jul 87)  on our 3130 IRIS. How can we implement
&gt; 	the ARS's function and what commands are used to create them?
There is no ARS editing capability.  The ones that we have were described
by typing in coordinates before MGED was ever written.
&gt; 	2. What are the commands to create "Rendered Splines" as shown on
&gt; 	plate caption 1.2 in your manual (i.e. how can we add a spline
&gt; 	surface to a mged model)?
MGED does not edit splines either.  We get our splines from the U. of Utah
Alpha_1 spline modeler and we have no intention of duplicating that
capability from within MGED, it is a very impressive geometric modeling
system in its own right.  If you want to get the Alpha_1 software,
I don't know the availability or supported hardware, but you can contact
Russ Fish &lt;russ@cs.utah.edu&gt; for information.  Paul Stay wrote some software
to convert the splines to MGED format, but it is not part of the
distribution.
&gt; 	3.Can one move the light source point in mged models (for rt)?
&gt; 	Can you also introduce extra light sources?
&gt; 	if so what commands are used?
Yes.  Check the RT manual page for this one, I'm not sure what version you
have, and this mechanism has undergone some changes.
&gt; 	4. Also could you tell me how to add a texture map to an
&gt; 	MGED model please. (either solid or object)?
This one is un-documented and subject to change, but I believe that the
material property string of a region (see the "mater" command of MGED),
can specify texture maps.  I will forward you an old message on the
subject, but its not really considered supported yet, just experimental,
so it may take some work on your part to make it do what you want.

<p>
Now, can you tell that I don't know what I'm talking about?
~moss
<hr>
Date:     Mon, 14 Dec 87 10:25:46 EST
From:     "Gary S. Moss" (VLD/VMB) &lt;moss@BRL.ARPA&gt;

<p>
	ARS stands for arbitrary surface and is a triangular-faceted
primitive described by a rectangular array of points.  See the paper
"Understanding the Preparation and Analysis of Solid Models" by Muuss
which follows the manual pages in your hardcopy documentation.  Fig.
1.8 and section 1.6.6 describe the ARS.  There is no facility for
editing these within MGED except for object-edit operations.  Most of
the existing ARS's were hand-built by typing coordinates in, you can
still do that, but I wouldn't recommend it.  B-splines or polygons
are more general primitives for describing surfaces, but the same
restrictions apply within MGED (object-edit only).  We use U. of Utah's
Alpha_1 software to create B-splines and convert them for input into
MGED models.

<p>
	AIR is air.  We need to model it for vulnerability analysis.
It is like solid material, but has some special properties.  It may
overlap solid objects and will automatically be displaced by them
(as far as the ray tracer is concerned) without causing overlap
diagnostics.  However, there are different types of air (i.e. engine
compartment air, crew air, etc.) and these must not overlap.  The type
of the air is indicated by a non-zero integer in the region record
(sometimes refered to as "air code") and should have a zero "id"
(sometimes refered to as "region id").  So, one or the other of region
id and air code must be zero.  There is a flag in the ray tracing
library (librt) that by default is set to ignore air.  If you have an
application that cares about it, you must set this flag.  In other
words, if you don't need to model air, just try to ignore it.

<p>
	The MATER command in MGED allows one to assign a character
string description of the material making up a region.  The RT program
parses this string using a specific language.  This is still in high
flux and is therefore not documented or used by any but the developers.
The only documentation is the source code for RT.  The supported means
of describing material properties is with the material id or "GIFTmater"
field of the region.  This is an index into a data base.  The LGT
program has a facility to create, modify and print these data bases,
but, in general, the ids are application specific.

<p>
	We have not modeled the cruise missile at all.

<p>
Hope this helps, I would be happy to answer more specific question also.

<p>
~moss
<hr>
Date:     Thu, 28 Jul 88 23:24:35 EDT
From:     Phil Dykstra &lt;phil@BRL.ARPA&gt;

<p>
I'm no Tektronix expert, and I have no experience running mged on
a Tek, but I think the situation there is something like this:

<p>
We have a 4014 module called "tek" and a 4109 (I assume that means
color?) module from NRTC called "tek4109".  To get the crosshairs
to work requires that the display be in "graphics mode," BUT (the
catch), you can't type regular commands to mged while in graphics
mode.  So, there are two ways to live with this problem:

<p>
1) If your tek display is connected to a host computer running mged,
   start up mged on some OTHER terminal, and when is asks "Output
   tty [stdout]?" enter the /dev/ttyXX line of the Tek display.
   This way terminal input can be done on the other terminal and
   the graphics output (including crosshairs) is done on the Tek.

<p>
2) From a Tek (or emulator), answer the "Output..." question with
   "/dev/tty", i.e. your self.  This will cause the system to switch
   in and out a graphics mode (after a CR I believe), so you can
   move the mouse (or crosshairs), type CR, give a command to mged,
   type CR, move the mouse, type CR, give a command to mged, type
   CR, ....

<p>
As you can see, its pretty crude.  If anyone makes any improvements
to the Tek situation, we would be happy to get them back.

<p>
- Phil
<hr>
Date:     Sat, 13 Aug 88 21:20:02 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;

<p>
I have created a new program called "buffer", which reads (and buffers)
all of stdin until EOF, then sends all the buffered data to stdout.
This is sometimes useful in complex pipelines.
	-Mike
<hr>
Date:     Thu, 11 Aug 88 3:23:25 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;

<p>
/dev/sgi21 gives NTSC, centered, non-lingering, shared memory.  FYI.
Also, vas4 has been modified to take a -F flag, so that it can open
a window to grab video from.  I have successfully recorded a little bit
this way, and except for the bad black levels, it seems to work.
	-M
<hr>
Date:     Tue, 16 Aug 88 12:12:36 EDT
From:     Bill Mermagen Jr.   &lt;wm@BRL.MIL&gt;

<p>
	Both methods will work. The first requires writing code to create
the mged script which would be executed by mged file.g &lt; script and look
something like:

<p>
	in name1
	rpp
	0 1 0 1 0 1
	in name2
	rpp
	2 3 2 3 2 3
	q

<p>
Or you can write a code which should look alot like this using libwdb:
( I called the code "conman" for convert man )

<p>
/*						*/
/*	Set up code for creating rpp's. 	*/
/*	Parts are in psuedo code.		*/
/*						*/
/*	conman -n inputfilename &gt; output.g	*/
/*						*/

<p>
#include &lt;stdio.h&gt;
#include &lt;math.h&gt;
#include "machine.h"
#include "db.h"
#include "vmath.h"

<p>
main(argc,argv)

<p>
int	argc;
char	*argv[];
point_t   min, max;
char	*name;
{
	argc--,argv++;

<p>
	if (argc &lt; 1){
	   fprintf(stderr, "usage: conman [ -n ][ filename ]\n");
	   exit(1);
	}

<p>
/* Read command line arguments */

<p>
	while (argc &gt; 0 && argv[0][0] == '-') {
		switch (argv[0][1]) {

<p>
		case 'n':
			nflg = 0;
			argc--,argv++;
			break;

<p>
		case 'd':
			debug = 1;
			argc--,argv++;
			break;

		default:
			fprintf(stderr,
			    "usage: conman [ -n ][ filename ]\n");
			exit(1);
		}
		argc--, argv++;
	}
	if((fd = open( cmanfile, 0664)) &lt; 0)
	         {
                        fprintf(stderr,"conman: Can't open %s\n",cmanfile);
                        exit(1);
	         }
	mk_id(stdout,cmanfile);

<p>
/* Stay in loop until all entities have been created, i.e. eof */
/*	while not end of file */{
		/* Read parameters */

<p>
			VSET(min,xmin,ymin,zmin);	/* Set variables */
			VSET(max,xmax,ymax,zmax);
			sprintf(name,"cman.%d",param); /* Create name of rpp */

<p>
			/* Create rpp */
			mk_rpp(stdout, name, min, max );
	} /* while not eof control loop */

<p>
}/* End of program */

<p>

<p>
If you have any difficulties making these work, give me a call.

<p>

<p>
				Good Luck!,

<p>
					Bill
<hr>
Date:     Fri, 19 Aug 88 6:57:53 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;

<p>
This evening, Phil and I removed the limit of 128 solids per region
that rt_bool_eval() had imposed.  It is now dynamic, in such a way
that will also work on the multiprocessors.
	-Mike
<hr>
Received: from spark.brl.mil by SEM.BRL.MIL id aa09866; 19 Sep 88 6:14 EDT
Date:     Mon, 19 Sep 88 6:14:08 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       ACST@BRL.MIL
cc:       Moss@BRL.MIL, Gwyn@BRL.MIL, CJohnson@BRL.MIL, PHD@BRL.MIL,
          Davisson@BRL.MIL
Subject:  New rle-fb
Message-ID:  &lt;8809190614.aa09313@SPARK.BRL.MIL&gt;

<p>
spark:/m/cad/util/rle-fb.[c1] contains the source and manual pages
for the new RLE-FB program, which handles existing (Edition-2) and
new (Edition-3, or Utah Raster Toolkit) format RLE files.
Please take a look, and let me know what you think.

<p>
I will be trying this program on a bunch of older images from VGR
Monday evening as a final test;  so far I have only tested it on
Goulds.  My final additions were from home this weekend, so I could not
verify that everything still works, being unable to see any pictures.
Therfore, I have postponed the BRL-CAD installation until Monday evening
(19th), to allow time for a full set of tests.  (Obviously, this is
one of the most "user visible" programs).

<p>
	Best,
	 -Mike
<hr>
<hr>
Received: from vmb.brl.mil by SEM.BRL.MIL id aa13529; 10 Sep 88 8:37 EDT
Received: from VMB.BRL.MIL by VMB.brl.MIL id aa18156; 10 Sep 88 7:52 EDT
Received: from spark.brl.mil by VMB.BRL.MIL id aa18142; 10 Sep 88 7:43 EDT
Date:     Sat, 10 Sep 88 7:35:38 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
To:       CAD@BRL.MIL
Subject:  Release 3.0 test at BRL
Message-ID:  &lt;8809100735.aa12119@SPARK.BRL.MIL&gt;

<p>
On Friday, 16-Sept, after COB, I will install the Release 3.0 software
on BRL's VAXen and Goulds (VGR and VMB, rdist will do the rest), plus on
the Suns served by SPARK and the SGIs served by VECTOR.  This message
is intended to be a "heads up" warning, to alert people of the impending
change.

<p>
This software has been ported to quite a few machines, and
we have been using it daily on the Crays, SPARK, our SGIs, and our Suns,
so I have high confidence in it.  However, as with any major software
release, there is some possibility of problems, which we will fix
as rapidly as possible.  All the present software will be moved to
".bak" names, so that nothing should be a show-stopper.

<p>
The only known incompatability is that .RLE files written with non-linear
colormaps will display as black, due to the change in the interpretation
of the colormap area of the .RLE header.  Other than that, the Edition-2
to Edition-3 change in the .RLE format is upwards compatible (but not
backwards compatible).  "rle-fb" will become "orle-fb" to permit reading
old format files with non-linear colormaps.  The advantage to this change
is that it allows the full suite of Utah Raster Toolkit software to be
used with our .RLE files, eg, those saved with fb-rle, etc.

<p>
When the software has run for a few days without serious difficulty,
it will also be installed on VECTOR (the Alliant), the Crays, and
any non-rdist machines that want it.

<p>
Once problems have been addressed, this software will be bundled up
and Release 3.0 will be formalized.  My target is still 30-Sept.

<p>
	Best,
	 -Mike

<p>
<hr>
<hr>
Received: from vmb.brl.mil by SEM.BRL.MIL id aa13117; 15 Oct 88 0:09 EDT
Received: from VMB.BRL.MIL by VMB.brl.MIL id aa04211; 15 Oct 88 0:08 EDT
Received: from spark.brl.mil by VMB.BRL.MIL id aa04153; 15 Oct 88 0:01 EDT
Date:     Sat, 15 Oct 88 0:01:03 EDT
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
To:       CAD@BRL.MIL
Subject:  Release 3.0
Message-ID:  &lt;8810150001.aa24968@SPARK.BRL.MIL&gt;

<p>
It is finally here.  Tapes have been spinning for the past
couple of days now.

<p>
<hr>

<p>
		  BRL-CAD Release 3.0
		    10 October 1988

<p>
Supported Machines:
	Alliant FX/8, FX/80
	Ardent	(preliminary)			New
	Convex C1				New
	Cray X-MP UNICOS 3.0.10
	Cray-2 UNICOS 4.0
	DEC Vax-11 4.2 BSD, 4.3 BSD
	ETA-10 (preliminary)			New
	Gould PN6080, PN9080
	Pyramid 9820				New
	SGI 3030
	SGI 4D (version 2+MEX)			New
	SGI 4D (version 3.1+4Sight)		New
	SGI 4D/GT				New
	Stellar (preliminary)			New
	Sun 3
	Sun 4					New

<p>
New MGED Interfaces:
	X Window System (X11R2)
	PostScript output
	A much improved SunWindow interface

<p>
New Frame Buffer Support:
	SGI 4Ds
	Preliminary X11R2 interface
	Enhanced Sun interface (shared memory, pans, zooms)
	Stackable devices
	fbhelp - help on FB_FILE options available

<p>
Other New Software:
	Extended UnixPlot support
	   Color, 3D command, IEEE floating point plotting
	   Display programs for SGI's, Frame buffers, X
	   Rotate, convert, debug utilities
	libwdb - for writing MGED databases from programs
	RLE - now compatible with current Utah Toolkit programs
	Contributed Software
	   Utah Raster Toolkit Release 2.0
	   The "Standard Procedural Databases" package
	   Cake - a make replacement

<p>
Numerous Bug Fixes and Enhancements:
	Most notably to LIBRT, RT, and MGED

<p>
New Manual:
  The manual has grown significantly and has split into two parts.
  There is now a separate 260 page MGED manual.

<p>
New Installation Procedure:
  We now use a program called "cake" ("make" ran out of steam).  For the
  above listed machines we can now detect what kind we are running on and
  configure things accordingly.  We are also now able to compile binarys
  for multiple types of machines from one source tree.


<hr>
<a href="mailto:mike@arl.mil">
  &lt;<em> mike@arl.mil </em>&gt;
  </a>

<br>
<a href="index.html"> Release notes for other versions of BRL-CAD </a>
</body>
